System and console for monitoring and managing tripping operations at a well site

ABSTRACT

A well advisor system and console for monitoring and managing tubular tripping operations at a well site. The system may be accessed through one or more workstations, or other computing devices, which may be located at a well site or remotely. The system is in communication with and receives input from various sensors. It collects real-time sensor data sampled during operations at the well site. The system processes the data, and provides nearly instantaneous numerical and visual feedback through a variety of graphical user interfaces (“GUIs”), which are presented in the form of an operation-specific console. The input and data provides information related to tubular tripping operations at a well site.

This application claims benefit of and priority to U.S. ProvisionalApplication No. 61/987,832, filed May 2, 2014, and is entitled tobenefit of that priority date. The specification, figures, appendicesand complete disclosure of U.S. Provisional Application No. 61/987,832are incorporated herein in their entireties by specific reference forall purposes.

FIELD OF INVENTION

This invention relates generally to oil and gas well drilling andproduction, and related operations. More particularly, this inventionrelates to a computer-implemented system for monitoring and managing theperformance of well drilling operations such as tripping or casingrunning operations.

BACKGROUND OF THE INVENTION

It is well-known that the drilling of an oil or gas well, and relatedoperations, is responsible for a significant portion of the costsrelated to oil and gas exploration and production. In particular, as newwells are being drilled into remote or less-accessible reservoirs, thecomplexity, time and expense to drill a well have substantiallyincreased.

Accordingly, it is important that drilling operations be completedsafely, accurately, and efficiently. With directional drillingtechniques, and the greater depths to which wells are being drilled,many complexities are added to the drilling operation, and the cost andeffort required to respond to a problem during drilling are high. Thisrequires a high level of competence from the driller or drillingengineer at the drilling rig (or elsewhere) to safely drill the well asplanned.

A “well plan” specifies a number of parameters for drilling a well, andis developed, in part, based on a geological model. A geological modelof various subsurface formations is generated by a geologist from avariety of sources, including seismic studies, data from wells drilledin the area, core samples, and the like. A geological model typicallyincludes depths to the various “tops” that define the formations (theterm “top” generally refers to the top of a stratigraphic orbiostratigraphic boundary of significance, a horizon, a fault, a porepressure transition zone, change in rock type, or the like. Geologicalmodels usually include multiple tops, thereby defining the presence,geometry and composition of subsurface features.

The well plan specifies drilling parameters as the well bore advancesthrough the various subsurface features. Parameters include, but are notlimited to, mud weight, drill bit rotational speed, and weight on bit(WOB). The drilling operators rely on the well plan to anticipate topsand changes in subsurface features, account for drilling uncertainties,and adjust drilling parameters accordingly.

In many cases, the initial geological model may be inaccurate. The depthor location of a particular top may be off by a number of feet. Further,since some geological models recite distances based on the distancebetween two tops, an error in the absolute depth of one top can resultin errors in the depths of multiple tops. Thus, a wellbore can advanceinto a high pressure subsurface formation before anticipated.

Such errors thus affect safety as well as cost and efficiency. It isfundamental in the art to use drilling “mud” circulating through thedrill string to remove cuttings, lubricate the drill bit (and perhapspower it), and control the subsurface pressures. The drilling mudreturns to the surface, where cuttings are removed, and is thenrecycled.

In some cases, the penetration of a high pressure formation can cause asudden pressure increase (or “kick”) in the wellbore. If not detectedand controlled, a “blowout” can occur, which may result in failure ofthe well. Blowout preventers (“BOP”) are well known in the art, and areused to protect drilling personnel and the well site from the effects ofa blowout. A variety of systems and methods for BOP monitoring andtesting are known in the art, including “Blowout Preventer TestingSystem and Method,” U.S. Pat. No. 7,706,890, and “Monitoring the Healthof Blowout Preventer,” US 2012/0197527, both of which are incorporatedherein in their entireties by specific reference for all purposes.

Conversely, if the mud weight is too heavy, or the wellbore advancesinto a particularly fragile or fractured formation, a “lost circulation”condition may result where drilling mud is lost into the formationrather than returning to the surface. This leads not only to theincreased cost to replace the expensive drilling mud, but can alsoresult in more serious problems, such as stuck drill pipe, damage to theformation or reservoir, and blowouts.

Similar problems and concerns arise during other well operations, suchas running and cementing casing and tubulars in the wellbore, wellborecompletions, or subsurface formation characterizations.

Drills strings and drilling operations equipment include a number ofsensors and devices to measure, monitor and detect a variety ofconditions in the wellbore, including, but not limited to, hole depth,bit depth, mud weight, choke pressure, and the like. This data can begenerated in real-time, but can be enormous, and too voluminous forpersonnel at the drilling site to review and interpret in sufficientdetail and time to affect the drilling operation. Some of the monitoreddata may be transmitted back to an engineer or geologist at a remotesite, but the amount of data transmitted may be limited due to bandwidthlimitations. Thus, not only is there a delay in processing due totransmission time, the processing and analysis of the data may beinaccurate due to missing or incomplete data. Drilling operationscontinue, however, even while awaiting the results of analysis (such asan updated geological model).

A real-time drilling monitor (RTDM) workstation is disclosed in“Drilling Rig Advisor Console,” U.S. application Ser. No. 13/312,646,which is incorporated herein by specific reference for all purposes. TheRTDM receives sensor signals from a plurality of sensors and generatessingle graphical user interface with dynamically generated parametersbased on the sensor signals.

Likewise, an intelligent drilling advisor system is disclosed in“Intelligent Drilling Advisor,” U.S. Pat. No. 8,121,971, which isincorporated herein by specific reference for all purposes. Theintelligent advisor system comprises an information integrationenvironment that accesses and configures software agents that acquiredata from sensors at a drilling site, transmit that data to theinformation integration environment, and drive the drilling state andthe drilling recommendations for drilling operations at the drillingsite.

SUMMARY OF INVENTION

In various embodiments, the present invention comprises a well advisorsystem for monitoring and managing well drilling and productionoperations. The system may be accessed through one or more workstations,or other computing devices. A workstation comprises one or morecomputers or computing devices, and may be located at a well site orremotely. The system can be implemented on a single computer system,multiple computers, a computer server, a handheld computing device, atablet computing device, a smart phone, or any other type of computingdevice.

The system is in communication with and receives input from varioussensors. In general, the system collects real-time sensor data sampledduring operations at the well site, which may include drillingoperations, running casing or tubular goods, completion operations, orthe like. The system processes the data, and provides nearlyinstantaneous numerical and visual feedback through a variety ofgraphical user interfaces (“GUIs”).

The GUIs are populated with dynamically updated information, staticinformation, and risk assessments, although they also may be populatedwith other types of information. The users of the system thus are ableto view and understand a substantial amount of information about thestatus of the particular well site operation in a single view, with theability to obtain more detailed information in a series of additionalviews.

In one embodiment, the system is installed at the well site, and thusreduces the need to transmit date to a remote site for processing. Thewell site can be an offshore drilling platform or land-based drillingrig. This reduces delays due to transmitting information to a remotesite for processing, then transmitting the results of that processingback to the well site. It also reduces potential inaccuracies in theanalysis due to the reduction in the data being transmitted. The systemthus allows personnel at the well site to monitor the well siteoperation in real time, and respond to changes or uncertaintiesencountered during the operation. The response may include comparing thereal time data to the current well plan, and modifying the well plan.

In yet another embodiment, the system is installed at a remote site, inaddition to the well site. This permits users at the remote site tomonitor the well-site operation in a similar manner to a user at thewell-site installation.

In some exemplary embodiments, the system is a web-enabled application,and the system software may be accessed over a network connection suchas the Internet. A user can access the software via the user's webbrowser. In some embodiments, the system performs all of thecomputations and processing described herein and only display data istransmitted to the remote browser or client for rendering screendisplays on the remote computer. In another embodiment, the remotebrowser or software on the remote system performs some of thefunctionality described herein.

Sensors may be connected directly to the workstation at the well site,or through one or more intermediate devices, such as switches, networks,or the like. Sensors may comprise both surface sensors and downholesensors. Surface sensors include, but are not limited to, sensors thatdetect torque, revolutions per minute (RPM), and weight on bit (WOB).Downhole sensors include, but are not limited to, gamma ray, pressurewhile drilling (PWD), and resistivity sensors. The surface and downholesensors are sampled by the system during drilling or well siteoperations to provide information about a number of parameters.Surface-related parameters include, but are not limited to, thefollowing: block position; block height; trip/running speed; bit depth;hole depth; lag depth; gas total; lithography percentage; weight on bit;hook load; choke pressure; stand pipe pressure; surface torque; surfacerotary; mud motor speed; flow in; flow out; mud weight; rate ofpenetration; pump rate; cumulative stroke count; active mud systemtotal; active mud system change; all trip tanks; and mud temperature (inand out). Downhole parameters include, but are not limited to, thefollowing: all FEMWD; bit depth; hole depth; PWD annular pressure; PWDinternal pressure; PWD EMW; PWD pumps off (min, max and average); drillstring vibration; drilling dynamics; pump rate; pump pressure; slurrydensity; cumulative volume pumped; leak off test (LOT) data; andformation integrity test (FIT) data. Based on the sensed parameters, thesystem causes the processors or microprocessor to calculate a variety ofother parameters, as described below.

In several embodiments, the system software comprises a database/server,a display or visualization module, one or more smart agents, one or moretemplates, and one or more “widgets.” The database/server aggregates,distributes and manages real-time data being generated on the rig andreceived through the sensors. The display or visualization moduleimplements a variety of GUI displays, referred to herein as “consoles,”for a variety of well site operations. The information shown on aconsole may comprise raw data and calculated data in real time.

Templates defining a visual layout may be selected or created by a userto display information in some portions of or all of a console. In someembodiments, a template comprises an XML file. A template can bepopulated with a variety of information, including, but not limited to,raw sensor data, processed sensor data, calculated data values, andother information, graphs, and text. Some information may be static,while other information is dynamically updated in real time during thewell site operation. In one embodiment, a template may be built bycombining one or more display “widgets” which present data or otherinformation. Smart agents perform calculations based on data generatedthrough or by one or more sensors, and said calculated data can then bedisplayed by a corresponding display widgets.

In one exemplary embodiment, the system provides the user the option toimplement a number of consoles corresponding to particular well siteoperations. In one embodiment, consoles include, but are not limited to,rig-site fluid management, BOP management, cementing, and casingrunning. A variety of smart agents and other programs are used by theconsoles. Smart agents and other programs may be designed for use by aparticular console, or may be used by multiple consoles. A particularinstallation of the system may comprise a single console, a sub-set ofavailable consoles, or all available consoles.

Agents can be configured, and configuration files created or modified,using the agent properties display. The same properties are used foreach agent, whether the agent configuration is created or imported. Thespecific configuration information (including, but not limited to,parameters, tables, inputs, and outputs) varies depending on the smartagent. Parameters represent the overall configuration of the agent, andinclude basic settings including, but not limited to, start and stopparameters, tracing, whether data is read to a log, and other basicagent information. Tables comprise information appearing in databasetables associated with the agent. Inputs and outputs are the input oroutput mnemonics that are being tracked or reported on by the agent. Forseveral embodiments, in order for data to be tracked or reported on,each output must have an associated output. This includes, but is notlimited to, log and curve information.

In one embodiment, the system comprises a Tripping Console used to planand monitor all tripping-in and tripping-out operations for casing,drill and completion strings, including BHA assemblies, both with norotary movement, and with rotary movement (e.g., as with reaming-downand backreaming operations). It captures and displays, in real time ornear real-time (e.g., within 10 to 20 seconds), at least the followinginformation for all tripping states: hookload; block position; blockvelocity; flow rate; and surface pressure.

The Tripping Console comprises several widgets. A Make-Up Torque Widgetmonitors the make-up torque signatures as each joint of a completionsstring is made up prior to running into the wellbore. The torqueresponse measured during the winding of a completion joint provides realtime or near real time information about the make-up to help determineif the joint was made up within acceptable tolerances. A warningindicator and success indicator can be provided. In one embodiment, thesuccess indicator is the assessment made by a service company or vendor,while the warning indicator is displayed if the analysis of the dataraises concerns about the torque signature for that joint (e.g., themake-up torque exceeds a running average value by a pre-set percentage).

A Completions Schematic Widget provides a well tubular completionschematic as a visual schematic, with corresponding columns for MD andTVD (in meters), description of the components, maker type, minimuminner diameter, maximum outer diameter, drift, length, materialelastomer information, other component information. and comments. Theschematic also include well information, wellhead data, tubing data,casing data, and liner data. The user can examine a detailed display ofa selected section of the tubular schematic.

An Activity Widget displays the accumulative and individual activitiesthat occur for a particular sequence. And a Drag Chart Widget monitorstubular trips over the lifetime of a run for a given hole section (e.g.,multiple trips of a given drill string or particular tubular object,such as a particular BHA). Actual and modelled hookloads are shownagainst measured depth (MD), for a series of trips into the well.Associated rotating data parameters (e.g., RPM, surface torque) may bedisplayed.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a view of a system in accordance with an embodiment of thepresent invention.

FIG. 2 shows a software architecture in accordance with variousembodiments of the present invention.

FIG. 3 shows a smart agent management toolbar.

FIG. 4 shows a smart agent management menu.

FIG. 5 shows a smart agent configuration file import menu.

FIG. 6 shows a smart agent configuration display screen.

FIG. 7 shows a smart agent configuration file export menu.

FIG. 8 shows a smart agent configuration file download display screen.

FIG. 9 shows a smart agent configuration file copy menu.

FIG. 10 shows an example of a hookload and block velocity chart.

FIG. 11 shows an example of a torque and drill string RPM chart.

FIG. 12 shows a Joint Signature Widget display.

FIG. 13 shows a Joint Torque Signature display.

FIG. 14 shows a Make-Up Torque Widget display with thumbnails.

FIG. 15 shows a Make-Up Torque Widget tabular display.

FIG. 16 shows a Hookload Signature Chart display with thumbnails.

FIGS. 17-19 shows examples of Completions Schematic Widget displays.

FIG. 20 shows an Activity Widget display.

FIG. 21-22 show examples of Drag Chart Widget displays.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS Computing EnvironmentContext

The following discussion is directed to various exemplary embodiments ofthe present invention, particularly as implemented into asituationally-aware distributed hardware and software architecture incommunication with one or more operating drilling rigs. However, it iscontemplated that this invention may provide substantial benefits whenimplemented in systems according to other architectures, and that someor all of the benefits of this invention may be applicable in otherapplications. For example, while the embodiments of the invention may bedescribed herein in connection with wells used for oil and gasexploration and production, the invention also is contemplated for usein connection with other wells, including, but not limited to,geothermal wells, disposal wells, injection wells, and many other typesof wells. One skilled in the art will understand that the examplesdisclosed herein have broad application, and that the discussion of anyparticular embodiment is meant only to be exemplary of that embodiment,and not intended to suggest that the scope of the disclosure, includingthe claims, is limited to that embodiment.

In order to provide a context for the various aspects of the invention,the following discussion provides a brief, general description of asuitable computing environment in which the various aspects of thepresent invention may be implemented. A computing system environment isone example of a suitable computing environment, but is not intended tosuggest any limitation as to the scope of use or functionality of theinvention. A computing environment may contain any one or combination ofcomponents discussed below, and may contain additional components, orsome of the illustrated components may be absent. Various embodiments ofthe invention are operational with numerous general purpose or specialpurpose computing systems, environments or configurations. Examples ofcomputing systems, environments, or configurations that may be suitablefor use with various embodiments of the invention include, but are notlimited to, personal computers, laptop computers, computer servers,computer notebooks, hand-held devices, microprocessor-based systems,multiprocessor systems, TV set-top boxes and devices, programmableconsumer electronics, cell phones, personal digital assistants (PDAs),network PCs, minicomputers, mainframe computers, embedded systems,distributed computing environments, and the like.

Embodiments of the invention may be implemented in the form ofcomputer-executable instructions, such as program code or programmodules, being executed by a computer or computing device. Program codeor modules may include programs, objections, components, data elementsand structures, routines, subroutines, functions and the like. These areused to perform or implement particular tasks or functions. Embodimentsof the invention also may be implemented in distributed computingenvironments. In such environments, tasks are performed by remoteprocessing devices linked via a communications network or other datatransmission medium, and data and program code or modules may be locatedin both local and remote computer storage media including memory storagedevices.

In one embodiment, a computer system comprises multiple client devicesin communication with at least one server device through or over anetwork. In various embodiments, the network may comprise the Internet,an intranet, Wide Area Network (WAN), or Local Area Network (LAN). Itshould be noted that many of the methods of the present invention areoperable within a single computing device.

A client device may be any type of processor-based platform that isconnected to a network and that interacts with one or more applicationprograms. The client devices each comprise a computer-readable medium inthe form of volatile and/or nonvolatile memory such as read only memory(ROM) and random access memory (RAM) in communication with a processor.The processor executes computer-executable program instructions storedin memory. Examples of such processors include, but are not limited to,microprocessors, ASICs, and the like.

Client devices may further comprise computer-readable media incommunication with the processor, said media storing program code,modules and instructions that, when executed by the processor, cause theprocessor to execute the program and perform the steps described herein.Computer readable media can be any available media that can be accessedby computer or computing device and includes both volatile andnonvolatile media, and removable and non-removable media.Computer-readable media may further comprise computer storage media andcommunication media. Computer storage media comprises media for storageof information, such as computer readable instructions, data, datastructures, or program code or modules. Examples of computer-readablemedia include, but are not limited to, any electronic, optical,magnetic, or other storage or transmission device, a floppy disk, harddisk drive, CD-ROM, DVD, magnetic disk, memory chip, ROM, RAM, EEPROM,flash memory or other memory technology, an ASIC, a configuredprocessor, CDROM, DVD or other optical disk storage, magnetic cassettes,magnetic tape, magnetic disk storage or other magnetic storage devices,or any other medium from which a computer processor can readinstructions or that can store desired information. Communication mediacomprises media that may transmit or carry instructions to a computer,including, but not limited to, a router, private or public network,wired network, direct wired connection, wireless network, other wirelessmedia (such as acoustic, RF, infrared, or the like) or othertransmission device or channel. This may include computer readableinstructions, data structures, program modules or other data in amodulated data signal such as a carrier wave or other transportmechanism. Said transmission may be wired, wireless, or both.Combinations of any of the above should also be included within thescope of computer readable media. The instructions may comprise codefrom any computer-programming language, including, for example, C, C++,C#, Visual Basic, Java, and the like.

Components of a general purpose client or computing device may furtherinclude a system bus that connects various system components, includingthe memory and processor. A system bus may be any of several types ofbus structures, including, but not limited to, a memory bus or memorycontroller, a peripheral bus, and a local bus using any of a variety ofbus architectures. Such architectures include, but are not limited to,Industry Standard Architecture (ISA) bus, Micro Channel Architecture(MCA) bus, Enhanced ISA (EISA) bus, Video Electronics StandardsAssociation (VESA) local bus, and Peripheral Component Interconnect(PCI) bus.

Computing and client devices also may include a basic input/outputsystem (BIOS), which contains the basic routines that help to transferinformation between elements within a computer, such as during start-up.BIOS typically is stored in ROM. In contrast, RAM typically containsdata or program code or modules that are accessible to or presentlybeing operated on by processor, such as, but not limited to, theoperating system, application program, and data.

Client devices also may comprise a variety of other internal or externalcomponents, such as a monitor or display, a keyboard, a mouse, atrackball, a pointing device, touch pad, microphone, joystick, satellitedish, scanner, a disk drive, a CD-ROM or DVD drive, or other input oroutput devices. These and other devices are typically connected to theprocessor through a user input interface coupled to the system bus, butmay be connected by other interface and bus structures, such as aparallel port, serial port, game port or a universal serial bus (USB). Amonitor or other type of display device is typically connected to thesystem bus via a video interface. In addition to the monitor, clientdevices may also include other peripheral output devices such asspeakers and printer, which may be connected through an outputperipheral interface.

Client devices may operate on any operating system capable of supportingan application of the type disclosed herein. Client devices also maysupport a browser or browser-enabled application. Examples of clientdevices include, but are not limited to, personal computers, laptopcomputers, personal digital assistants, computer notebooks, hand-helddevices, cellular phones, mobile phones, smart phones, pagers, digitaltablets, Internet appliances, and other processor-based devices. Usersmay communicate with each other, and with other systems, networks, anddevices, over the network through the respective client devices.

By way of further background, the term “software agent” refers to acomputer software program or object that is capable of acting in asomewhat autonomous manner to carry out one or more tasks on behalf ofanother program or object in the system. Software agents can also haveone or more other attributes, including mobility among computers in anetwork, the ability to cooperate and collaborate with other agents inthe system, adaptability, and also specificity of function (e.g.,interface agents). Some software agents are sufficiently autonomous asto be able to instantiate themselves when appropriate, and also toterminate themselves upon completion of their task.

The term “expert system” refers to a software system that is designed toemulate a human expert, typically in solving a particular problem oraccomplishing a particular task. Conventional expert systems commonlyoperate by creating a “knowledge base” that formalizes some of theinformation known by human experts in the applicable field, and bycodifying some type of formalism by way the information in the knowledgebase applicable to a particular situation can be gathered and actionsdetermined. Some conventional expert systems are also capable ofadaptation, or “learning”, from one situation to the next. Expertsystems are commonly considered to be in the realm of “artificialintelligence.”

The term “knowledge base” refers to a specialized database for thecomputerized collection, organization, and retrieval of knowledge, forexample in connection with an expert system. The term “rules engine”refers to a software component that executes one or more rules in aruntime environment providing among other functions, the ability to:register, define, classify, and manage all the rules, verify consistencyof rules definitions, define the relationships among different rules,and relate some of these rules to other software components that areaffected or need to enforce one or more of the rules. Conventionalapproaches to the “reasoning” applied by such a rules engine inperforming these functions involve the use of inference rules, by way ofwhich logical consequences can be inferred from a set of asserted factsor axioms. These inference rules are commonly specified by means of anontology language, and often a description language. Many reasoners usefirst-order predicate logic to perform reasoning; inference commonlyproceeds by forward chaining and backward chaining.

The present invention may be implemented into an expert computerhardware and software system, implemented and operating on multiplelevels, to derive and apply specific tools at a drilling site from acommon knowledge base, including, but not limited to, information frommultiple drilling sites, production fields, drilling equipment, anddrilling environments. At a highest level, a knowledge base is developedfrom attributes and measurements of prior and current wells, informationregarding the subsurface of the production fields into which prior andcurrent wells have been or are being drilled, lithology models for thesubsurface at or near the drilling site, and the like. In this highestlevel, an inference engine drives formulations (in the form of rules,heuristics, calibrations, or a combination thereof) based on theknowledge base and on current data. An interface to human expertdrilling administrators is provided for verification of these rules andheuristics. These formulations pertain to drilling states and drillingoperations, as well as recommendations for the driller, and also includea trendologist function that manages incoming data based on the qualityof that data, such management including the amount of processing andfiltering to be applied to such data, as well as the reliability levelof the data and of calculations therefrom.

At another level, an information integration environment is providedthat identifies the current drilling sites, and drilling equipment andprocesses at those current drilling sites. Based upon thatidentification, and upon data received from the drilling sites, serversaccess and configure software agents that are sent to a host clientsystem at the drilling site; these software agents operate at the hostclient system to acquire data from sensors at the drilling site, totransmit that data to the information integration environment, and toderive the drilling state and drilling recommendations for the drillerat the drilling site. These software agents include one or more rules,heuristics, or calibrations derived by the inference engine, and calledby the information integration environment. In addition, the softwareagents sent from the information integration environment to the hostclient system operate to display values, trends, and reliabilityestimates for various drilling parameters, whether measured orcalculated.

The information integration environment is also operative to receiveinput from the driller via the host client system, and to act as aknowledge base server to forward those inputs and other results to theknowledge base and the inference engine, with verification or input fromthe drilling administrators as appropriate.

According to another aspect of the invention, the system develops aknowledge base from attributes and measurements of prior and currentwells, and from information regarding the subsurface of the productionfields into which prior and current wells have been or are beingdrilled. According to this aspect of the invention, the systemself-organizes and validates historic, real time, and/or near real timedepth or time based measurement data, including information pertainingto drilling dynamics, earth properties, drilling processes and drillerreactions. This drilling knowledge base suggests solutions to problemsbased on feedback provided by human experts, learns from experience,represents knowledge, instantiates automated reasoning and argumentationfor embodying best drilling practices.

According to yet another aspect of the invention, the system includesthe capability of virtualizing information from a well being drilledinto a collection of metalayers, such metalayers corresponding to acollection of physical information about the layer (material properties,depths at a particular location, and the like) and also information onhow to successfully drill through such a layer, such metalayersre-associating as additional knowledge is acquired, to manage real-timefeedback values in optimizing the drilling operation, and in optimizingthe driller response to dysfunction. Normalization into a continuum,using a system of such metalayers, enables real-time reaction topredicted downhole changes that are identified from sensor readings.

According to another aspect of the invention, the system is capable ofcarrying out these functions by creating and managing a network ofsoftware agents that interact with the drilling environment to collectand organize information for the knowledge base, and to deliver thatinformation to the knowledge base. The software agents in this networkare persistent, autonomous, goal-directed, sociable, reactive,non-prescriptive, adaptive, heuristic, distributed, mobile andself-organizing agents for directing the driller toward drillingoptimization, for collecting data and information, and for creatingdynamic transitional triggers for metalayer instantiation. Thesesoftware entities interact with their environment through an adaptiverule-base to intelligently collect, deliver, adapt and organizeinformation for the drilling knowledge base. According to this aspect ofthe invention, the software agents are created, modified and destroyedas needed based on the situation at the drilling rig, within the field,or at any feasible knowledge collection point or time instance withinthe control scope of any active agent.

According to another aspect of the invention, the software agents in thenetwork of agents are controlled by the system to provide therecommendations to the drillers, using one or more rules, heuristics,and calibrations derived from the knowledge base and current sensorsignals from the drilling site, and as such in a situationally awaremanner. In this regard, the software agents interact among multiplesoftware servers and hardware states in order to provide recommendationsthat assist human drillers in the drilling of a borehole into the earthat a safely maximized drilling rate. The software “experts” dispatchagents, initiate transport of remote memory resources, and providetransport of knowledge base components including rules, heuristics, andcalibrations according to which a drilling state or drillingrecommendation is identified responsive to sensed drilling conditions incombination with a selected parameter that is indicative of a metalayerof the earth, and in combination with selected minimums and maximums ofthe drilling equipment sensor parameters. The software experts developrules, heuristics, and calibrations applicable to the drilling sitederived from the knowledge base that are transmitted via an agent to adrilling advisor application, located at the drilling site, that iscoupled to receive signals from multiple sensors at the drilling site,and also to one or more servers that configure and service multiplesoftware agents.

According to another aspect of the invention, the system is applied tocirculation actors to optimize circulation, hydraulics at the drill bitpoint of contact with the medium being drilled, rationalization ofdistributed pressure and temperature measurements and to providerecommendations to avoid or recover from loss of circulation events.

In addition, while this invention is described in connection with amultiple level hardware and software architecture system, in combinationwith drilling equipment and human operators, it is contemplated thatseveral portions and facets of this invention are separately andindependently inventive and beneficial, whether implemented in thisoverall system environment or if implemented on a stand-alone basis orin other system architectures and environments. Those skilled in the arthaving reference to this specification are thus directed to considerthis description in such a light.

Well Advisor System and Consoles

FIG. 1 illustrates a workstation showing a well advisor system 100 inaccordance with various exemplary embodiments of the present invention.The workstation comprises one or more computers or computing devices,and may be located at a well site or remotely. The system can beimplemented on a single computer system, multiple computers, a computerserver, a handheld computing device, a tablet computing device, a smartphone, or any other type of computing device.

The system is in communication with and receives input from varioussensors 120, 130. In general, the system collects real-time sensor datasampled during operations at the well site, which may include drillingoperations, running casing or tubular goods, completion operations, orthe like. The system processes the data, and provides nearlyinstantaneous numerical and visual feedback through a variety ofgraphical user interfaces (GUIs).

The GUIs are populated with dynamically updated information, staticinformation, and risk assessments, although they also may be populatedwith other types of information, as described below. The users of thesystem thus are able to view and understand a substantial amount ofinformation about the status of the particular well site operation in asingle view, with the ability to obtain more detailed information in aseries of additional views.

In one embodiment, the system is installed at the well site, and thusreduces the need to transmit date to a remote site for processing. Thewell site can be an offshore drilling platform or land-based drillingrig. This reduces delays due to transmitting information to a remotesite for processing, then transmitting the results of that processingback to the well site. It also reduces potential inaccuracies in theanalysis due to the reduction in the data being transmitted. The systemthus allows personnel at the well site to monitor the well siteoperation in real time, and respond to changes or uncertaintiesencountered during the operation. The response may include comparing thereal time data to the current well plan, and modifying the well plan.

In yet another embodiment, the system is installed at a remote site, inaddition to the well site. This permits users at the remote site tomonitor the well-site operation in a similar manner to a user at thewell-site installation.

The architecture of the system workstation shown in FIG. 1 is only oneexample of multiple possible architectures. In one embodiment, theworkstation comprises one or more processors or microprocessors 102coupled to one or more input devices 104 (e.g., mouse, keyboard,touchscreen, or the like), one or more output devices 106 (e.g.,display, printer, or the like), a network interface 108, and one or morenon-transitory computer-readable storage devices 110. In someembodiments, the input and output devices may be part of the workstationitself, while in other embodiment such devices may be accessible to theworkstation through a network or other connection.

In one exemplary embodiment, the network interface may comprise awire-based interface (e.g., Ethernet), or a wireless interface (e.g.,BlueTooth, wireless broadband, IEEE 802.11x WiFi, or the like), whichprovides network connectivity to the workstation and system to enablecommunications across local and/or wide area networks. For example, theworkstation can receive portions of or entire well or cementing plans orgeological models 117 from a variety of locations.

The storage devices 110 may comprise both non-volatile storage devices(e.g., flash memory, hard disk drive, or the like) and volatile storagedevices (e.g., RAM), or combinations thereof. The storage devices storethe system software 115 which is executable by the processors ormicroprocessors to perform some or all of the functions describe below.The storage devices also may be used to store well plans, geologicalmodels 117, configuration files and other data.

In some exemplary embodiments, the system is a web-enabled application,and the system software may be accessed over a network connection suchas the Internet. A user can access the software via the user's webbrowser. In some embodiments, the system performs all of thecomputations and processing described herein and only display data istransmitted to the remote browser or client for rendering screendisplays on the remote computer. In other embodiments, the remotebrowser or software on the remote system performs some of thefunctionality described herein.

Sensors 120, 130 may be connected directly to the workstation at thewell site, or through one or more intermediate devices, such asswitches, networks, or the like. Sensors may comprise both surfacesensors 120 and downhole sensors 130. Surface sensors include, but arenot limited to, sensors that detect torque, revolutions per minute(RPM), and weight on bit (WOB). Downhole sensors include, but are notlimited to, gamma ray, pressure while drilling (PWD), and resistivitysensors. The surface and downhole sensors are sampled by the systemduring drilling or well site operations to provide information about anumber of parameters. Surface-related parameters include, but are notlimited to, the following: block position; block height; trip/runningspeed; bit depth; hole depth; lag depth; gas total; lithographypercentage; weight on bit; hook load; choke pressure; stand pipepressure; surface torque; surface rotary; mud motor speed; flow in; flowout; mud weight; rate of penetration; pump rate; cumulative strokecount; active mud system total; active mud system change; all triptanks; and mud temperature (in and out). Downhole parameters include,but are not limited to, the following: all FEMWD; bit depth; hole depth;PWD annular pressure; PWD internal pressure; PWD EMW; PWD pumps off(min, max and average); drill string vibration; drilling dynamics; pumprate; pump pressure; slurry density; cumulative volume pumped; leak offtest (LOT) data; and formation integrity test (FIT) data. Based on thesensed parameters, the system causes the processors or microprocessor tocalculate a variety of other parameters, as described below.

FIG. 2 provides an example of the system software architecture. Thesystem software comprises a database/server 150, a display orvisualization module 152, one or more smart agents 154, one or moretemplates 156, and one or more “widgets” 160. The database/server 150aggregates, distributes and manages real-time data being generated onthe rig and received through the sensors. The display or visualizationmodule 152 implements a variety of graphical user interface displays,referred to herein as “consoles,” for a variety of well site operations.The information shown on a console may comprise raw data and calculateddata in real time.

Templates 156 defining a visual layout may be selected or created by auser to display information in some portions of or all of a console. Insome embodiments, a template comprises an XML file. A template can bepopulated with a variety of information, including, but not limited to,raw sensor data, processed sensor data, calculated data values, andother information, graphs, and text. Some information may be static,while other information is dynamically updated in real time during thewell site operation. In one embodiment, a template may be built bycombining one or more display “widgets” 160 which present data or otherinformation. Smart agents 154 perform calculations based on datagenerated through or by one or more sensors, and said calculated datacan then be displayed by a corresponding display widgets.

In one exemplary embodiment, the system provides the user the option toimplement a number of consoles corresponding to particular well siteoperations. In one embodiment, consoles include, but are not limited to,rig-site fluid management, BOP management, cementing, and casingrunning. A variety of smart agents and other programs are used by theconsoles. Smart agents and other programs may be designed for use by aparticular console, or may be used by multiple consoles. A particularinstallation of the system may comprise a single console, a sub-set ofavailable consoles, or all available consoles.

In various embodiments, smart agents in the system can be managed with atoolbar 200 (as seen in FIG. 3) or by a drop-down menu 210 (as seen inFIG. 4), which may be activated by clicking on a smart agent icon,right-click on a mouse button, or the like. Functions include, but arenot limited to, adding a new agent 202 a, copying an agent configuration202 b, importing 202 c or exporting 202 d an agent configuration file,deleting an agent 202 e, refreshing the status of an agent 202 f, orstarting or stopping an agent.

For certain smart agents, an agent configuration file must be imported220 to use the smart agent, as seen in FIG. 5. In one embodiment,configuration files are denominated as *.agent files. Selecting theimport option provides the user the option to enter the configurationfile name, or browse to a location where the configuration file isstored.

Agents can be configured, and configuration files created or modified,using the agent properties display, as seen in FIG. 6. The sameproperties are used for each agent, whether the agent configuration iscreated or imported. The specific configuration information (including,but not limited to, parameters, tables, inputs, and outputs) variesdepending on the smart agent. Parameters 232 represent the overallconfiguration of the agent, and include basic settings including, butnot limited to, start and stop parameters, tracing, whether data is readto a log, and other basic agent information. Tables 234 compriseinformation appearing in database tables associated with the agent.Inputs 236 and outputs 238 are the input or output mnemonics that arebeing tracked or reported on by the agent. For several embodiments, inorder for data to be tracked or reported on, each output must have anassociated output. This includes, but is not limited to, log and curveinformation.

Users can export an agent configuration file for other users to importand use. The export configuration button in the toolbar can be used fora selected agent, or the agent can be right-clicked on and the exportconfiguration option 240 chosen, as shown in FIG. 7. The user confirms242 the action to download the file to a local hard drive or other filestorage location, as seen in FIG. 8. The user may name the file asdesired. Once downloaded, the file can be copied, emailed, or otherwisetransferred to another user for importation and use.

Copying an agent configuration 244, as seen in FIG. 9, allows the userto copy an agent configuration file and rename it. This saves the userfrom having to perform an initial setup of the agent properties orcreate a new configuration file multiple times, if the user has agentconfigurations that are similar. In one embodiment, the user rightclicks on the desired agent, selects the copy option, and identifies thewellbore for which the configuration is to be used. The user can name orrename the new agent configuration.

The Well Advisor system and related consoles are described more fully in“System and Console for Monitoring and Managing Well Site Operations,”U.S. patent application Ser. No. 14/196,307, which is incorporatedherein in its entirety by specific reference for all purposes.

Tripping (Completions) Console

The Tripping Console is related to the Casing Running Console, and usesand extends the Hookload Signature Widgets and Drag Chart Widgets, aswell as other smart agents and widgets used therewith. The CasingRunning Console is described more fully in “System and Console forMonitoring and Managing Casing Running Operations at a Well Site,” U.S.patent application Ser. No. 14/208,796, which is incorporated herein inits entirety by specific reference for all purposes.

The Tripping Console is used to plan and monitor all tripping-in andtripping-out operations for casing, drill and completion strings,including BHA assemblies, both with no rotary movement, and with rotarymovement (e.g., as with reaming-down and backreaming operations). Itcaptures and displays, in real time or near real-time (e.g., within 10to 20 seconds), at least the following information for all trippingstates: hookload; block position; block velocity; flow rate; and surfacepressure. FIG. 10 shows an example of a visual chart provided for theTripping Console, showing hookload 302 (in k lbs) and block velocity 304(in meters per minute) for measured depth 300 (in meters). Where thereis rotary movement, the Tripping Console also captures and displayssurface torque 312 and drill string RPM 314 as a function of time, asseen in FIG. 11. These may be combined through a Joint Signature Widget,with a display as seen in FIG. 12, which also shows block position 316as a function of time.

The Make-Up Torque Widget monitors the make-up torque signatures as eachjoint of a completions string is made up prior to running into thewellbore. The torque response measured during the winding of acompletion joint provides real time or near real time information aboutthe make-up to help determine if the joint was made up within acceptabletolerances.

An example of a display 320 showing the torque signature for a joint isshown in FIG. 13. It shows the measured torque data 322 as compared tomanufacturer data 324 and an envelope 326 of a certain number of mostrecent successful make-ups. A warning indicator 332 and successindicator 330 can be provided. In one embodiment, the success indicatoris the assessment made by a service company or vendor, while the warningindicator is displayed if the analysis of the data raises concerns aboutthe torque signature for that joint (e.g., the make-up torque exceeds arunning average value by a pre-set percentage). RPM data 328 also may bepresented.

FIG. 14 shows another example of a display 320 from the Make-Up TorqueWidget, which provides a number of thumbnail views 320 a, b, c ofadjacent joints. The number of thumbnails may be configured by the user.In addition to warning indicators, the border of each thumbnail may becolored to reflect an alert status (e.g., green/amber/red). The user maybrowse the thumbnails to review successive joints and thus, historicalmake-ups. A tabular view 330 may also be provided, as seen in FIG. 15.

The thumbnail strip (with or without colored borders) may also be usedto display Hookload Signature charts 340 a, b, c, as seen in FIG. 16.

In the case of completions strings, the console uses a CompletionsSchematic Widget that provides additional information beyond thatprovided by the 2D-Wellbore Schematic Widget. Examples of displaysproduced by the Completions Schematic Widget are shown in FIGS. 17-19.Displays include a 2-D schematic of the BHA 350.

FIG. 17 shows a well tubular completion schematic as a visual schematic,with corresponding columns for MD and TVD 352 (in meters), descriptionof the components 354, maker type 356, minimum inner diameter 358,maximum outer diameter 360, drift 362, length 364, material elastomerinformation 366, other component information 368, and comments 370. Theschematic also include well information 372, wellhead data 374, tubingdata 376, casing data 378, and liner data 380.

FIGS. 18 and 19 shows examples of a detailed display of a selectedsection 400 of the tubular schematic. The diagram in the schematicviewer may be produced from WITSML completions object data source, a CADmodel, a PDF file, an HTML image with an image map that is used toinvoke tabular data popups containing metadata about the selected regionof the image, or an SWB compliant XML file. The user may zoom into partsof the diagram, or use scroll bars to pan or move the image in variousdirections. Particular components in the image may be selected orhovered over, causing a popup window 402 to appear containing data aboutthe selected region of the image. A tabular view 404 of the componentsand related data may also be displayed. The display may be contextsensitive. In some embodiment, the user may edit or populate object datafor components in the schematic.

The Activity Widget displays the accumulative and individual activitiesthat occur for a particular sequence, as seen in FIG. 20. For example,the pie chart 420 shows the accumulative total time breakdown forspecified activities (e.g., coring, hole opening, connection, reaming,drilling, rig up and tear down). The linear display 422 shows eachindividual activity occurrence on a time-based axis for each activitybound by the active or selected sequence.

The Drag Chart Widget monitors tubular trips over the lifetime of a runfor a given hole section (e.g., multiple trips of a given drill stringor particular tubular object, such as a particular BHA), as seen in FIG.21. Actual and modelled hookloads 440 are shown against measured depth(MD) 442, for a series of trips into the well. Associated rotating dataparameters (e.g., RPM 452, surface torque 454) may be displayed on aseparate chart, as seen in FIG. 22.

Thus, it should be understood that the embodiments and examplesdescribed herein have been chosen and described in order to bestillustrate the principles of the invention and its practicalapplications to thereby enable one of ordinary skill in the art to bestutilize the invention in various embodiments and with variousmodifications as are suited for particular uses contemplated. Eventhough specific embodiments of this invention have been described, theyare not to be taken as exhaustive. There are several variations thatwill be apparent to those skilled in the art.

What is claimed is:
 1. A system for improving computer-based processingand monitoring of tubular tripping operations at a well site,comprising: a plurality of sensors to sample or detect parametersrelated to tubular tripping operations at a well site, said plurality ofsensors comprising surface sensors or downhole sensors or a combinationthereof; one or more computing devices adapted to receive parameterinformation in real time from said plurality of sensors during a tubulartripping operation, said one or more computing devices each furthercomprising a processor or microprocessor, said processor ormicroprocessor adapted to process the received parameter information tocalculate derived parameters related to the tubular tripping operation;at least one computer-readable storage medium for storing some or all ofsaid received parameter information and said derived parameters; and avisual display, coupled to said one or more computing devices, fordisplaying in real time some or all of the received parameterinformation and said derived parameters.
 2. The system of claim 1, saidone or more computing devices further comprising at least one softwaresmart agent having one or more formulations applicable to said drillingoperations.
 3. The system of claim 1, wherein the visual display showsone or more make-up torque signatures of a joint of a tubularcompletions string.
 4. The system of claim 3, wherein the visual displayshows a plurality of views of make-up torque for adjacent joints in thetubular completions string.
 5. The system of claim 1, said one or morecomputing devices further comprising one or more software widgets. 6.The system of claim 5, wherein said one or more software widgetscomprise a make-up torque widget adapted to determine and displaymake-up torque for a joint.
 7. The system of claim 5, wherein said oneor more software widgets comprise a completions schematic widget adaptedto create and display a visual schematic of a tubular completionsstring.
 8. The system of claim 5, wherein said one or more softwarewidgets comprise a activity widget adapted to create and display a chartof time spent on individual activities for a tripping operationssequence.
 9. The system of claim 5, wherein said one or more softwarewidgets comprise a drag chart widget adapted to create and display adrag chart of multiple tripping operation sequences for a section of thewell.
 10. A method for improving computer-based processing andmonitoring of tubular tripping operations at a well site, comprising thesteps of: receiving, using a processor or microprocessor, tubulartripping operations parameter information from a plurality of sensors,said plurality of sensors comprising surface sensors or downhole sensorsor a combination thereof; calculating in real time, using said processoror microprocessor, one or more derived parameters from the receivedpressure testing parameter information; and displaying in real time, ona visual display, some or all of the received parameter information andthe one or more derived parameters.
 11. The method of claim 10, whereinthe step of displaying comprises displaying one or more make-up torquesignatures of a joint of a tubular completions string.
 12. The method ofclaim 10, wherein the step of displaying comprises displaying aplurality of views of make-up torque for adjacent joints in the tubularcompletions string.
 13. The method of claim 10, wherein the step ofdisplaying comprises displaying a visual schematic of a tubularcompletions string.
 14. The method of claim 10, wherein the step ofdisplaying comprises displaying a chart of time spent on individualactivities for a tripping operations sequence.
 15. The method of claim10, wherein the step of displaying comprises displaying a drag chart ofmultiple tripping operation sequences for a section of the well.